美海军“联合航迹管理”（JTM）架构
“联合航迹管理”（Joint Track Architecture，简称JTM）是美舰队实现作战协同的重要保证，其项目目标是为一系列联合单元定义一个能够进行航迹管理的通用架构。这种通用化架构可以管理各类航迹、接收各种数据源输入，整合全局跟踪图，并将选定数据传播到其他JTM节点，实现探测数据共享，为后续打击作战做好铺垫。
因此，JTM对未来作战系统的快速更新及形成战斗力具备十分重要的意义。就此，本文针对JTM架构相关技术进行简要介绍，并详细阐述其功能和技术挑战。
文章仅供学习参考，观点不代表本机构立场。
浅谈美海军“联合航迹管理”（JTM）架构
作者：plus高级评论员 张昊
海军目前是美国第一大军种，其作战舰队在历次战争中都起到了关键作用，其典型作战任务包括区域防空、战术反导、对地打击等。但是，由于舰队雷达等传感器在探测距离和分辨精度的局限性，理论上单一军舰难以单独完美地执行上述作战任务，其作战样式需要与其它探测器以及相关作战平台进行作战协同，将探测到的目标数据整合，以支撑进行防空反导作战。
“联合航迹管理”（Joint Track Architecture，简称JTM）是美舰队实现作战协同的重要保证，其项目目标是为一系列联合单元定义一个能够进行航迹管理的通用架构，可对各类航迹进行管理，可接收来自各种数据源的航迹相关数据输入，对这些数据进行整合以形成全局跟踪图，并通过网络将选定数据传播到其他JTM节点，实现探测数据共享，并为后续打击作战做好铺垫。这种通用化架构的采用也将对未来作战系统的快速更新及形成战斗力具备重要意义。
目前，美国海军依靠各种作战系统为其水面舰艇提供能力。舰船上部署有高级作战指挥系统（Advanced Combat Direction System）、舰船自防御系统（SSDS）和宙斯盾作战系统，而DDG1000和濒海战斗舰已经开发了新的作战系统。虽然这些作战系统具有一些重叠的功能，但它们是独立开发的，每个系统都有一套独特的要求和系统架构，并且通常由不同的开发商开发。因此，很难重新使用或修改为先前或并行作战系统而开发的代码。此外，以往的作战系统倾向于定义其架构以使得系统内的组件紧密耦合。这种耦合也会妨碍重新使用现有功能的能力，并且限制了在不影响作战系统多个组件的情况下进行单独更改的能力。
近年来，海军越来越关注将开放式架构(OA)原则应用于未来作战系统开发，例如使用非专有硬件和商业操作系统。现有的水面作战系统已开始在其系统开发中应用这些开放式架构原则。
SSDS的设计就考虑到了开放式架构设计，“宙斯盾”系统也已经开始在最近的基线中实施开放式架构。尽管开放式架构原则的应用可以给每个单独的作战系统带来益处，但是它们独特的架构依然限制了多个作战系统之间的作战能力。因此，人们越来越关注开发可用于海军和联合平台的标准架构和通用功能。
JTM是一种旨在在作战系统内进行航迹管理的设计架构。
JTM架构由联合架构工作组(JAWG)开发，该工作组由来自陆军、海军、空军、海军陆战队、导弹防御局(MDA)和联合单一综合空图系统工程组织的各个组织代表组成，其构成包括架构、跟踪管理、作战识别和外部通信等多个团队。经过数月时间，JAWG及其相关小组召开会议并开发了定义JTM架构的产品。
架构团队开发了一系列“质量特征”以及用于实现这些质量特征的架构规则。质量特征是一种非功能性需求，通常在软件和系统工程共同体中被称为“性能”。举例而言，在规则相关文件中，“质量特征”的定义包括可用性、可扩展性、可承受性和可重用性。
为实现质量特征，JAWG开发了一组架构规则。这些架构规则定义了一组在开发JTM架构时应用的设计原则。这些设计原则融合了以往海军作战系统开发工作的经验和教训，包括可应用于任何系统架构的基本设计准则。下面将重点介绍几个对解决体系工程复杂性特别重要的规则。
信息模型/对象模型规则(Information Model/Object Model)为JTM架构提供了关键设计结构。它规定所有JTM组件应基于信息模型定义。该模型定义了系统内的所有信息。每个组件根据其唯一产生的信息（即，系统可用的信息）来定义。所有组件都可以访问系统中生成的所有信息，但信息产生者并不知道哪些组件使用了其信息。
根据组件化规则（Componentization precept）的规定，功能架构是根据产生和使用信息的组件来定义的，这与上述信息模型/对象模型规则一致。JTM文件引用了组件的几个定义，包括Booch等人的以下内容：“组件是系统中物理存在并可替代的一部分，能够匹配符合并提供一系列接口的实现”。组件是JTM架构的基本构建模块，根据它们执行的功能、所需要的信息以及产生的信息进行表征。上述定义适用于不同大小的组件；该规则的另一方面是每个组件在其自身范围内具有内聚性，同时与其他组件松散耦合。
分层设计的概念是指对架构进行定义，将功能分离成不同的层级，从而将每个层与较低层的知识隔离开来。这个概念的一个常见例子是使用一组库功能的标准接口来提供网络服务。应用程序可识别标准接口，但不了解底层执行。该设置限制了各层之间的依赖关系。只要标准接口没有改变，底层执行就可以改变，因此，应用程序不需要任何修改。这些规则在架构中的多个层面都应用了分层设计的概念。
在分层跟踪数据集成规则下，采用分层跟踪数据模型提供了一种机制，即在保存各种来源航迹数据的同时，允许更高层级的航迹以某种方式对源数据进行组合。较低层级的跟踪源被认为是支持源，而较高层级的跟踪被称为全局航迹（Global Track）。可通过融合较低层级的跟踪源或通过从可能用到的数据源进行选择来创建全局航迹特征，例如运动状态或识别。图1为是航迹数据模型的一个示例。
图1 航迹数据模型范例
（EW LOB是指电子战方位线，MTBFT是指虚假航迹间的平均时间）
JTM架构定义了一种航迹管理能力，用于接收来自各种数据源的航迹相关数据输入，对这些数据进行整合以形成全局跟踪图，并通过网络将选定数据传播到其他JTM节点。如前一节所述，JTM架构由其信息设计结构及其功能组件定义。JAWG中多个团队对JTM架构中的功能进行了定义，这些小组汇集了来自政府、实验室和行业的各方面专家，在特定功能区域中对JTM架构组件定义。每个组件都是由组件自身提供的功能描述及其输入和输出来定义的。这项工作的最终结果是所有JTM组件进行了功能描述。
图2是JTM子系统情况，对战术性联合航迹管理(Tactical JTM)和作战联合航迹管理（Operational JTM）进行了阐明。从图中可看到JTM架构集成了包括传感器、作战、通讯等多种系统。本文主要论述的内容为由JAWG所开发的战术性联合航迹管理。
图2 JTM子系统情况，包括指控系统、电子支援、ISR系统等多个部分
JTM的目标是为一系列联合单元定义一个能够进行航迹管理的通用架构，这具备很大的挑战性。这不仅需要跨多个系统执行必要的系统工程，还要考虑到具有不同需求、系统和操作限制的所有潜在用户。当项目团队定义各自的组件时，为满足不同系统可能的要求驱动了架构决策的发展。
下面将介绍一些架构决策的范例。
目前，海军在战斗群中的每艘舰艇或飞机上都装备“协同作战能力“（CEC）来提供通用空中航迹图像，这使得网络中每艘舰艇或飞机能够在一个复合航迹图中查看其他平台探测到的所有目标。CEC计算机收集数据并形成复合航迹图后，使用数据分配系统将其连接到网络。该数据分配系统是一种具有连接和中继功能，可从每个平台向网络中每个单元提供数据的射频通信系统。复合航迹处理将本地测量（来自自身单元上的传感器）与远程测量（来自其他单元）相结合，从而将对目标所有测量结果相关联，形成一条航迹，从而估计目标位置。这些测量数据形成的航迹集合就形成了复合航迹图像。
JTM的多重复合跟踪能力是JTM功能定义的重要方面。
这种复合跟踪算法应考虑到主机系统中的错误预留（Error Budget）以及战术数字信息链路。此外，能够在单个JTM单元上运行多个复合跟踪处理也是重点发展方向之一。例如，对于不同类型的传感器（例如，雷达传感器和电子支援传感器），可能存在不同的复合跟踪处理。该架构允许在单一单元上实体化多个复合跟踪组件来满足这种需求，这在图2中进行了展示。
此外，该架构还能够通过将每个复合处理都作为一个独立的支持源的方式，在全局航迹层面集成来自多个复合过程的数据。
当两个或多个复合过程探测到重叠区域中的跟踪信号时，在全局航迹层面进行集成来防止重复跟踪是必不可少的。第二个需求是可允许单个单元或单元组选择其自己的复合跟踪方案。JTM架构允许多个不同的复合网络同时运行，并可在全局航迹层面对不同复合网络的航迹进行集成。
上一段描述了在不需要共享传感器测量数据的前提下的多个复合跟踪网络上的作战需求，因此可以在全局航迹层面进行集成。此外，多个不同复合跟踪网络运行还需要一种高质量传感器数据共享能力，能够在这些网络之间共享高质量的传感器测量数据。JTM架构通过引入“桥接”（Bridging）概念来实现这一需求。桥接提供了一种机制，可维护每个网络上的航迹之间的关系，转换数据格式并根据需要映射航迹编号。2011财年，成功演示了美国陆军综合防空反导作战指挥系统复合网络与美国海军CEC复合网络的桥接原型能力。
使用组件架构可允许定制每个单元的功能，允许每个单元仅对其所需的那些组件进行实体化。举例来说，这种定制只在复合航迹层级操作的组件子集上实现，而忽略了与创建和维护全局航迹相关联的组件。但是，这些相同的单元仍需要具有评估其复合跟踪身份的能力，这对于识别潜在的威胁至关重要。各单元对全局航迹相关组件进行实体化，必须在全局航迹层级执行识别功能。为了满足这两个要求，定义了作战识别(ID)组件以允许在复合或全局航迹层级进行实体化。
分层跟踪数据模型假设可以在复合和全局航迹层级跨网络共享数据。随着网络越来越大，很明显带宽限制将阻碍所有数据共享，此时需要通过算法来确定哪些数据应该在受约束的环境中共享。JTM架构通过定义全局数据分发管理器和复合数据分发管理器组件来应对这一挑战。这些组件中，每一个组件都有责任针对其各自的跟踪层级确定应传输哪些数据。
综合作战系统计划执行办公室(PEO IWS)采用了一种采购作战系统软件的产品线(Product Line)方法，为海军水面单元定义了通用的软件架构以及构建/维护该软件架构组件的策略。产品线架构的共享规则类似于为JTM架构所定义的规则，并且产品线架构的航迹管理部分与JTM几乎相同，类似于是从该架构演变而来。
产品线架构比JTM架构更广泛，除航迹管理之外还包括作战系统能力。产品线架构将用于指导在通用资产库（Common asset library）中共用、可重用的软件组件的开发。政府将控制通用资产库以及由数据模型、功能分配和接口定义所指定的组件级架构。该架构将作为未来海军水面舰艇作战系统开发的基础。
正如海军水面平台各种作战系统图上所示，作战系统能力可通过多种方式实现。JAWG对于定义JTM架构的努力，诠释了根据各自舰艇的不同系统和要求，跨服务定义公共能力的复杂性。
随着海军和联合工作的推进，重要的是要认识到定义通用能力所固有的复杂性以及彻底了解所有潜在用户的要求和限制的必要性，以便能够在满足要求和限制条件下开发的能力。只有在所有相关组织之间开展广泛合作，才能实现JTM架构定义等工作。为确保对架构的所有方面有一致的理解以及使得系统所有功能得以正确实施，不同组织合作的需求远远超出了最初的描述。尽管开发通用架构的工程挑战巨大，但更大的挑战是基于这些架构去实现产品化。
鉴于不可能从头开始不断开发新的作战系统，有必要采用一种渐进的方法来开发与现有作战系统开发工作相协调的通用能力，从而最大限度地减少对这些作战系统时间表和预算的影响，这对于系统更新换代和快速形成战斗力有着重要的意义。
（全文完）
声明：版权归原作者所有。文章观点不代表本机构立场。
《中国电子科学研究院学报》欢迎各位专家、学者赐稿！投稿链接
http://kjpl.cbpt.cnki.net
学报电话：010-68893411
学报邮箱：dkyxuebao@vip.126.com